# Merged PRs
dolt
go-mysql-server

2331: fix NOT expression in conjunction with WHERE EXISTS(<subquery>)

The analyzer rule unnest_exists_subqueries was accidentally dropping NOT expressions when hoisting subqueries from WHERE EXISTS... clauses.

This should fix 8 sqllogictests.

Correctness: bump dolthub/dolt#7510
2330: Fix DISTINCT over DECIMALS

There was another place where we were using hashstructure package, which does not hash decimal.Decimal types correctly.

Switched to xxhash package, which is what we use everywhere else.

Reusing solution from: fix count distinct with decimals dolthub/go-mysql-server#2279

This will fix 1 sqllogictest.
2329: expression.Div Micro Benchmarks

There are going to be changes to our division behavior that impact both its accuracy and speed.

This PR adds benchmarks to track the runtime improvements/degradations
2326: Various Decimal Type Fixes

This PR has a variety of fixes to have arithmetic operations (especially those involving decimals) behave more like MySQL.

The logic for the Type() method for Arthmetic and Div is simpler, and better tested.

When comparing Decimal results from division operations, MySQL has an internal Scale that is different than the Scale used when returning Decimal results for display.

Here's a matrix displaying the resulting scale:

(Ex: 1 / 3 = 0.333333333; scale 0 div scale 0 should return scale 9)



Additionally, this PR adds test for arithmetic operations over Datetime and Year types. There are still a some problems dealing with precision and parsing there...

Note: I believe the division optimization where float division is preferred over decimal division for internal calculations may be causing problems. More testing is needed to see if it's possible to enable this without causing inaccuracies/precision loss.

There are microbenchmarks measuring the performance of div expression, and it turns out these changes actually greatly improve the runtime.

Correctness: bump dolthub/dolt#7484

Fixes

division operation should not truncate the result if it's in another function. dolthub/dolt#7207


2323: SQLEXCEPTION proc handler

We originally supported one type of procedure handler, NOT FOUND, which explicitly checked for an error when fetching from a cursor io.EOFs. The implementation for that handler would walk the entire BEGIN/END scope stack inside the Fetch call looking for a handler, execute the handler body, and then embed the scope height into a special return error. The error walked back up the callstack looking for the BEGIN/END block embedded in the error message.

This PR:

Refactors handlers to coordinate message passing in a centralized way. No metadata is embedded in FetchEOF, because each scope will explicitly compare its handlers to errors raised during execution within its BEGIN/END bounds. (FetchEOF is important because we differentiate between 3 different types of io.EOF in procedure loops).
Add type/object support for representing specific signal handers.
Add SQLEXCEPTION signal handling, which will trigger for any error type (other than io.EOF) that bubbles up during a BeginEndIter's execution.

re: Add support for handlers dolthub/dolt#7454

Another thing I noticed is that some of our tests return nil for empty stored procedures when mysql returns ERROR 1329 (02000): No data - zero rows fetched, selected, or processed. https://github.com/dolthub/dolt/issues/new



Closed Issues